The present invention relates generally to cryptography systems. More particularly, the present invention relates to an automated key management system that includes apparatus and methods for managing key material in heterogeneous cryptographic assets.
As an organization""s need to provide confidentiality and authenticated access to a user""s data increases, so does its need for cryptographic services. Cryptography provides a convenient way to ensure that data can be accessed (either remotely or locally) only by legitimate users with a valid xe2x80x9cneed to access,xe2x80x9d and that this data is accessed in a manner that keeps its content private to all but the legitimate accessing party. As the number of cryptographic devices used within an organization grows, the management of the key material needed to operate these devices becomes more difficult. Moreover, the organization is typically required to perform both symmetric and asymmetric key management.
An example of an organization that requires secure management of key material for a heterogeneous set of cryptographic devices is a bank. Many banking customers require secure remote access to their account balances and authenticated requests for account withdrawals. The banks themselves must be able to wire money from institution to institution in a secure and authenticated manner. Data confidentiality, data integrity, and data authenticity are obvious security requirements supporting these banking services.
Cryptography and cryptographic techniques provide a vehicle for achieving data confidentiality, data integrity, and data authenticity. As cryptography and cryptographic techniques are implemented, key management naturally follows. Traditionally, key management has tended to be a unique xe2x80x9cstove pipexe2x80x9d function implemented in each cryptographic system (e.g., a wire transfer system) as a unique dedicated key management system. The key management systems (which provide point solutions) are typically proprietary and are specifically tailored to one type of cryptographic equipment from one manufacturer. Additionally, existing key management systems tend to be highly user intensive. For example, distribution of key material to automated teller machines (ATMs) typically occurs via physical channels using two person control.
Traditionally, banks have addressed the key management needs for each banking service (e.g., ATM transactions, Electronic Funds Transactions (EFTs), etc.) as a separate and distinct consideration. As banks expand their set of services, however, to include, for example, remote xe2x80x9chome bankingxe2x80x9d and remote deployment of cash machines, each of these services will also require different key management to support the cryptography involved in implementing the service.
FIG. 1 provides an exemplary scenario in which a conventional key management system is employed in a banking network. As shown, an acquiring bank 58 is in communication with an issuing bank 50. Issuing bank 50 can be, for example, a bank in which a particular customer holds an account. Acquiring bank 58 can be, for example, a bank at which the customer initiates a transaction. For example, the customer might withdraw money from an ATM at acquiring bank 58. Acquiring bank 58 communicates the transaction to issuing bank 50 so that the banks can reconcile the transaction between them. Acquiring bank 58 and issuing bank 50 can be the same bank, or different banks.
Typically, banks communicate with one another via a financial network 54. Some well-known financial networks include Cirrus, Plus, S.W.I.F.T., etc. Financial network 54 facilitates the reconciliation of transactions between acquiring bank 58 and issuing bank 50. As shown, issuing bank 50 is in communication with financial network 54 via a public switched telephone network (PSTN) 52. Similarly, acquiring bank 58 is in communication with financial network 54 via a PSTN 56.
As shown, acquiring bank 58 can be in communication with an ATM 76, a home banking client 92, a wholesale banking terminal 64, and any number of other types of equipment. Preferably, acquiring bank 58 includes a wholesale server 60 that communicates via a PSTN 62 with wholesale banking terminal 64. Wholesale banking terminal 64 can be a computer or other workstation via which a wholesale banking operator can control electronic funds transfers (EFTs) for example. Acquiring bank 58 can also include an ATM host 72 that communicates via a PSTN 74 with ATM 76. Acquiring bank 58 can also include a home banking server 88 that interfaces via a communications network 90 with a home banking client 92. Typically, communications network 90 is the Internet, although it could be any communications network, such as a LAN, WAN, or intranet.
To maintain privacy and security on the communications network just described, cryptography is typically employed to secure the communications links. FIG. 1 shows the xe2x80x9cdisjointedxe2x80x9d key management of each banking service when a conventional key management system is employed. That is, each banking service (ATM, EFT, home banking, etc.) makes use of a separate key management system that is dedicated to that service. The system as a whole, therefore, comprises a plurality of key management systems, each of which is separately maintained.
For example, wholesale server 60 is also in communication via a key management (KM) interface 66 with a wholesale KM system 68. Wholesale KM system 68 is in communication via a KM interface 70 with wholesale banking terminal 64. Wholesale KM system 68 manages (i.e., generates and distributes) key material for wholesale banking terminal 64. Key material can include the key itself, as well as attributes that describe the key, such as its name, version, key type, expiration date, etc.
KM interfaces 66 and 70 can be separate physical interfaces, although, in general, they need not be. KM interfaces 66 and 70 are xe2x80x9cvirtualxe2x80x9d interfaces, i.e., they can include any vehicle by which wholesale KM system 68 can manage key material to secure the communications link between wholesale banking terminal 64 and wholesale server 60.
Similarly, ATM 76 is in communication via a KM interface 78 with an ATM KM system 80. ATM KM system 80 manages the key material for ATM 76. As shown, ATM host 72 can also interface with a network security processor (NSP) 82. NSP 82 is in communication via a KM interface 84 with an ATM host KM system 86. ATM host KM system 86 manages the key material for ATM host 72. ATM KM system 80 and ATM host KM system 86 typically share key material. Typically, ATM key management requires two person, physical delivery. That is, each of two persons is required to physically deliver part of a xe2x80x9csplitxe2x80x9d key to ATM 76. In this way, KM interfaces 78 and 84 are not physical interfaces, but virtual.
As home banking typically occurs via the Internet, home banking server 88 is usually coupled to a secure sockets layer (SSL) accelerator 98, which provides for secure communications over a public network such as the Internet. A home banking KM system 94 communicates via a KM interface 96 with home banking server 88. Home banking KM system 94 manages the key material for home banking client 92 via KM interfaces 93, 95.
To date, the limited number of ATMs and electronic transaction interfaces has allowed the less comprehensive xe2x80x9cpointxe2x80x9d key management systems to survive. With the explosion of remote ATMs (i.e., ATMs located in non-bank locations), the addition of numerous remote users, and the subsequent key management needs of each (i.e., each user requiring management of keying resources), the key management situation is fast becoming unmanageable. Additionally, the rapidity with which cryptographic algorithms become obsolete exacerbates the key management problem. It is well known that key management systems typically evolve from a cryptographic product; however, developers of key management systems typically develop these systems to support a particular cryptographic device. Since a single cryptographic device usually cannot support all of a user""s cryptographic needs, users are frequently required to manage many different types of devices using different key management systems.
It would be advantageous, therefore, to organizations such as banks to have a comprehensive integrated key management system that efficiently and securely manages all banking key management needs (e.g., from remote ATM to remote home banking user). That is, it would be much more efficient for an organization to use a single system that can handle multiple devices, than it would be to use many different key management systems to perform the same function. Similarly, consolidation and automation in a secure framework improves the efficiency and frequency of key management activities, thus making the cryptographic systems more secure. Thus, there is a need in the art for an automated, integrated, key management system for managing key material for a plurality of heterogeneous cryptographic assets.
The present invention satisfies these needs in the art by providing apparatus and methods for remotely rekeying a cryptographic device. A method according to the invention comprises associating a preliminary certificate with the device, and generating a device certificate associated with the device, determining whether a certificate stored in the device is the preliminary certificate associated with the device, and if the certificate stored in the device is the preliminary certificate associated with the device, then securely loading the device certificate into the device.
Associating the preliminary certificate with the device can include associating the preliminary certificate with a device identifier that corresponds to the device. Determining whether the certificate stored in the device is the preliminary certificate associated with the device can include determining whether the certificate has been previously used as a preliminary certificate associated with another cryptographic device.
The device certificate can have a public part and a private part. According to this aspect of the invention, securely loading the device certificate into the device can include encrypting the private part of the device certificate using a first encryption algorithm, generating a first packet comprising the public part, the encrypted private part, and a set of decryption instructions for decrypting the encrypted private part, encrypting the first packet using a second encryption algorithm, generating a second packet comprising the encrypted first packet and a set of decryption instructions for decrypting the encrypted second packet, and delivering the second packet to the device.
The inventive method can also include loading the preliminary certificate into the device. The preliminary certificate can be loaded into the device via a preliminary certificate loader.
Apparatus for remotely rekeying a cryptographic device can include a computer readable medium having stored thereon computer executable instructions for performing a method according to the invention. The apparatus can also include a preliminary certificate loader that receives the preliminary certificate from the computer readable medium, and delivers the preliminary certificate to the device.